The present invention relates to methods and apparatus for processing data within a computer network. More specifically, it relates to using NAT (network address translation) and IPSec (IP Security) protocols for such data.
For a particular computer to communicate with other computers or web servers within a network (e.g., the Internet), the particular computer must have a unique IP (Internet Protocol) address. IP protocol version 4 specifies 32 bits for the IP address, which theoretically gives about 4,294,967,296 unique IP addresses. However, there are actually only between 3.2 and 3.3 billion available IP addresses since the addresses are separated into classes and set aside for multicasting, testing and other special uses. With the explosion of the Internet, the number of IP addresses is not enough to give each computer a unique IP address.
One solution for addressing computers with the limited number of IP addresses is referred to as network address translation (NAT). NAT allows an intermediary device (e.g., computer, router or switch) located between the Internet network and a local network to serve as an agent for a group of local computers. A small range of IP addresses or a single IP address is assigned to represent the group of local computers. Each computer within the local group is also given a local IP address that is only used within that local group. However, the group's local IP addresses may duplicate IP address that are used outside of the local network. When a local computer attempts to communicate with a computer outside the local network, the intermediary device matches the local computer's local IP address (and port) to one of the intermediary device's assigned IP addresses (and ports). The intermediary device then replaces the local computer's local address (and port) with the matched assigned IP address (and port). This matched assigned IP address (and port) is then used to communicate between the local computer and the outside computer. Thus, NAT techniques allow local IP address to be reused across local networks.
Another solution to the lack of available IP addresses is to redesign the address format to allow for more possible IP addresses. The recent introduction of IPv6 provides 128 bits for the IP address, as compared with IPv4 which provides 32 bits for the IP address. However, until all network devices and computers are converted to IPv6, it is still necessary to allow an existing IPv4 device to communicate with an IPv6 device. One popular method that allows IPv4 to IPv6 communication is referred to as protocol translation (NAT-PT). The IP addresses are converted by NAT-PT from one protocol to another protocol (e.g., IPv4 to IPv6 or vice versa) or, more generally, from an external protocol to an internal protocol. In addition to the IP addresses, the NAT-PT also converts any relevant IPv4 or IPv6 information during a protocol translation.
The basic idea of NAT is to allow multiple users to share one external IP address on the internet. It also provides protection to the internal network, as the IP addresses on the internal network are not visible on the external side. As the number of computers each household has is increasing, most home networks are using NAT. There are also home gateways available which allow IPsec (IP security) or VPN (virtual private network) connections from the outside to the home. The IPSec protocol is generally described in “Security Architecture for the Internet Protocol”, RFC 2401, S. Kent et al., Network Working Group of IETF (November 1998), which document is herein incorporated by reference in its entirety.
A VPN emulates a private IP network over public or shared infrastructures. Virtual Private Networks provide advantages to both the service provider and its customers; For its customers, a VPN can extend the IP capabilities of a corporate site to remote offices and/or users with intranet, extranet, and dial-up services. This connectivity may be achieved at a lower cost to the customer with savings in capital equipment, operations, and services. The service provider is able to make better use of its infrastructure and network administration expertise offering IP VPN connectivity and/or services to its customers.
There are many ways in which IP VPN services may be implemented, such as, for example, Virtual Leased Lines, Virtual Private Routed Networks, Virtual Private Dial Networks, Virtual Private LAN Segments, etc. Additionally VPNs may be implemented using a variety of protocols, such as, for example, IP Security (IPSec) Protocol, Layer 2 Tunneling Protocol, Multiprotocol Label Switching (MPLS) Protocol, etc.
A conventional technique for implementing a VPN across a wide area network may be accomplished through the use of first an IKE (Internet Key Exchange) session to exchange keys and then an IPSec Protocol which establishes a secure IPSec communication session between two nodes. A number of issues arise when attempting to create a secure communication session with a node that sits behind a NAT device. Since the node behind the NAT has a private address, the external node that sits outside the NAT device is not aware of the inside node's address and cannot initiate a secure communication session with such inside node. In some implementations, one may configure the NAT gateway to also terminate the VPN connection and allow access between inside nodes and external nodes. As such, an external node can set up a secure IPSec session with the gateway and thereby have access to all inside nodes. However, this configuration is highly undesirable when the VPN connection is desired end-to-end with a single inside node. By way of example, a remote server may set up a secure connection to the gateway/NAT to deliver pay per view, encrypted movie content to one or more inside subscriber nodes. In this configuration, inside nodes that had not subscribed or paid for the movie content may have unintended access to the movie content as a result of a secure session being set up between the remote server and gateway, but insecure connections within the local network. Moreover, an implementation of a simple connection tracking module on the NAT-enabled gateway does not work for the IPSEC NAT-traversal as IKE+IPSEC do not use predefined ports and the ports to be used are dynamically allocated during handshaking for security reasons. So a connection tracking module which would work for example for protocol http using port 80, would not work for IKE+IPSEC NAT traversal.
A summary of some issues with NAT and IPSec are further discussed in “NAT TRAVERSAL: PEACE AGREEMENT BETWEEN NAT AND IPSEC” by Haluk AyDin, Aug. 12, 2001, published by the SANS Institute of Bethesda, Md. which paper is incorporated herein by reference in its entirety. The following documents also further describe the issues with using NAT and IPSec and are herein incorporated by reference in their entirety: (1) “RSIP Support for End-to-end IPsec”, RFC 3104, G. Montenegro et al., Network Working Group of IETF (October 2001), (2) “Security Model with Tunnel-mode IPSec for NAT Domain”, RFC 2709, P. Srisuresh et al., Network Working Group of IETF (October 1999), (3) “IPSec-Network Address Translation (NAT) Compatibility Requirements”, RFC 3715, B. Aboba et al., Network Working Group of IETF (March 2004).
In view of the above, there is a need for improved mechanisms for reliably and efficiently providing an IPSec connection with a host that resides behind a NAT device.